The Realities of Packet Radio in the Amateur Radio Service, 


or 


circa 1985 


How to deal with a user base. 


Harold E. Price, NK6K 


Abstract. 


The author postulates the existence of two 
major experimenter groups in amateur 
packet radio; those who experiment with 
data sent via packet radio and those who 
experiment with the way data is sent via 
packet radio. The problems .of these 
groups in the face of 5000 or more packet 
users by the time of the 5th ARRL 
networking conference are discussed. 


Let me preface this discussion by noting 
that some of the thoughts presented here 
were the result of rou discussions 
during a meeting of the ARRL Ad Hoc 
Digital Communications Committee in 1984. 
At that meeting, the major discussion was 
layer three networking. 


We have the privilege of witnessing the 
birth of a major force in amateur fadio, 
one that may even have a lasting effect on 
its future. It is clear that the majority 
of technically minded junior and senior 


high school kids are now taking up 
computers as a hobby instead of amateur 
radio as in years past. If any of the 
plans being set in motion by the ARRL, 
magazines, and manufacturer's groups are 
successful in bringing new blood to 
amateur radio, the technology oriented 
newcomers will surely bring their 


computers with them. Packet radio will be 
a carrot to attract new blood. 


In 1985, 
the amount of 


we will see a large increase in 
"press" the packet radio 


gets. 1984 was a good year, with major 
articles in the amateur press as well as 
such non-amateur publications as 'BYTE". 
There were also several peripheral 
mentions in PACSAT and UoSAT-11 articles 
in several areas; IEEE Institute, 
INFOWORLD, USA Today, Science, and others. 


1985 will see several more articles is 
such places as IEEE Spectrum and a special 
issue of IEEE Communications. The biggest 


increase in packet's visibility will come 
from new manufacturers entering the 
market. The number of advertising pages 


containing packet equipment will double or 
triple in the next few months. 


4.93 


The bottom line is that packet will 
continue to grow at an increasing’ rate. 
It has grown from 240 to more than 2400 
users in the last 14 months. It will at 
least double in the next year. As the 
growth of packet continues, so will the 
split between two groups, those who want 
to use the network, and those who want to 


build, 1. 
There are those involved in packet radio 
who want to "play" with networks. Here 


the word "play" is not used as in 
Webster's definition 2(vi) 1c(2) ".... to 
behave frivolously", but rather as in 
2(vi) 2b(2) "to move or operate ina 
lively, irregular, or intermittent 
manner". Those packeteers with the right 
stuff wish to push the edges of the 
envelope. They in particular, to judge 
from conversations that spring up at all 
gatherings where networking is discussed, 


wish to experiment with routing schemes. 
Zip codes, area codes, grid squares, 
zones, directions, random chance, casting 


of bones, any number of schemes are 


waiting to be tried. 


Then there is the other group of packet 
users who wish to take the existence of a 
network for granted and get on with using 
its Emergency nets, tornado spotting, 
traffic handling, newsletter distribution, 
public service events, earthquake 
detection (presumably by detecting a drop 
in traffic from California), and other 
data utilization topics are discussed in 


user's forums. The old term "appliance 
user" doesn't apply to these folks, 
anymore than it did to an oldtime op who 


didn't draw his own wire from an ingot to 
make a cat whisker for his crystal set. 
As we move into the future, the size and 
inner complexity of the basic building 
blocks changes. A good example of this is 


the WORLI store and forward message 
system. No knowledge of the inner 
workings of the AX.25 protocol was 


required to use a TNC for a building block 


to create something new, a way to get 
messages passed automatically between 
local area nets, and over HF, VHF, and 
Oscar 10. 


Both groups need each other. A network 
must be designed and built to provide the 
services required by user community. And 


on the other hand, a network is no fun if 


how can you get enjoyment 
out of providing an elegant bottleneck 
avoidance algorithm if no one creates 
bottlenecks in the first place? 


it has no users: 


As the number of AX.25 TNCS grows, it 
becomes more difficult to make radical 
changes to them. The "TNC" will become a 
basic building block, it will have a set 
of assumed functions and a set place in 
the scheme of things, at least for a few 
years. As an example, when someone says 
"Grab your two meter HT and come help out 
in the marathon", there is almost no 
question that it will be compatible with 
all other two meter HTs. It will put out 
1-2 watts, be somewhere around 5 KHz 
deviation, and can be moved to any .005 
MHz channel in the 144 to 147.995 range. 
There remain a few rockbound amateurs, 
just as there are still some TAPR 1.0 roms 
and Vl VADCG boards around, but you get 
the idea. 


As it turns out, the requirement to build 
a network while not making any changes to 
the basic user TNC is a feature, not a 
bug. It forces a network design that 
isolates the inner workings of the long 
haul routing network from the general 
user. The result is a much smaller number 
of network routing devices. The smaller 
the number of devices and people involved, 
the more often changes can be made. 


Figure 1 shows the architecture of a 
network that meets the goals stated above, 
requires no changes to the basic TNC, and 
reduces the number of devices with direct 
networking capability. In this diagram, 
users, denoted by boxes containing a 2 to 
show the highest protocol layer in use, 
connect to a network access node. Several 
users can connect at a time, and more than 
one frequency can be used. They establish 
a standard AX.25 connection with the 
device, and enter into a conversation with 
it to begin the connection process to some 
other network user. This is analogous to 
picking up a telephone handset. When you 
do SO, you are "connected" to the 
telephone network. You tell the network 
who you want to talk to by entering an 
identification code. It is not necessary 
to know how the connection is made, only 
how to access the network (pick up the 
handset) and make a_ connection with 
another user (dial the number). The only 
other knowledge required is recognition of 
various error messages; busy, fast busy, a 
number of "We're sorry" messages, anda 
timeout on no action. 


These same error messages will be present 
on a packet radio network access node. 
Since a network implementation will most 


likely be staged, the initial messages 
will be quite simplistic, perhaps even the 


familiar CONNECTED and RETRY COUNT 
EXCEEDED. 
In Figure 1, the ---- connection lines are 
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the standard AX.25 protocol. Lines marked 
as can be any other protocol, 
although most planners have agreed to use 
AX.25 as the layer two protocol with 
various higher layers added on top. The 
important point is that the exact details 
of the connections between boxes marked 
III need not be known by the majority of 
packet users. As long as the interface 
between the user and the network access 
node (the boxes labeled III) stays the 
same, the network gurus can change the 
network at will so long as’ connectivity 
and throughput are maintained. 


= 
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A final interesting point in figure 1 is 
the bottom left hand user. Since AX.25 is 
used for access to the network simple 
digipeating can still be used by those on 
the fringes of local area nets. The added 
expense of a network access node is not 
required for users in very low activity 
areas. 


Here is an example of the type of exchange 
that would take place between a user and 
the network access node. The actual data 


sent and received is in upper case, 
comments are in lower case and delimited 
by {}. 


CONNECT NLA 
*** CONNECTED TO NLA 
NORTH LA NETWORK ACCESS NODE HERE. 


{ A connection is established toa 
network access node. Node names need not 
be callsigns, the node could identify 
every 10 minutes with a UI frame.1 


DI STATUS 
{The user asks for status. 
anything could be displayed here } 


Almost 


THERE ARE 5 OTHER USERS CONNECTED. 
SB LINK IS UP 

EASTLA LINK IS DOWN 

SD LINK IS UP 


{The list of connected network nodes is 
displayed. In the first networks, this 
will tell a user who he can expect to 
reach, based on his knowledge of the 
network. In the next 12 months, network 
nodes will be few in number and big in 
fanfare, so each local users will know the 
topology. A help file could be provided 
on the node for those who didn't} 


CONNECT K6XXX @SFO 
***CONNECTION ESTABLISHED. 


{A connection via some number of III boxes 
is initiated and established.1 


Once the connection is made, a transparent 
path is established through the network 
node, and data is passed directly to 
K6XXX, who is reached through the SFO 


network node. An escape sequence similar 
to the transparent mode escape on the TAPR 
TNC or standard "smart modem” devices can 
be used to get back to the network node 
command level. 


This method of network access allows for a 


staged implementation, something that is 
extremely likely to occur in the real 
world. When the network is simple, the 


network access program can be complex, 
allowing paths to be specified explicitly. 
As the network becomes smarter in routing, 
the connect command becomes simpler, until 
it is finally CONNECT W3IWI. 


The intent here has been to quickly 
describe a way to implement a more complex 
network than is currently available while 
at the same time minimizing the impact of 
network construction on the majority of 
packet users. Many schemes are underfoot 
to provide network access devices, and the 
protocols to connect them. TAPR has 
agreed to work on the network node access 
protocol (the language used to "talk" to 
the node and get connected to someone at 
another node) Several people have 
suggested the use of the A.3/X.28/A.29 
protocols for TNC and network access node 
control. It is beyond the scope of this 
paper to go into depth on the exact access 
protocol or the network protocol itself, 
but it is hopefully not beyond the efforts 
of the amateur packet radio community. 
Let's get connected for Christmas. 
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